fix(jsx-runtime): fix automatic runtime implementation #7959
Conversation
The JSX automatic runtime consists of two modules. These modules require different exports. - `vue/jsx-runtime` is for production. This has the following exports: - `jsx` - `jsxs` - `Fragment` - `vue/jsx-dev-runtime` is for development. This has the following exports: - `jsxDEV` - `Fragment` Whereas a JSX pragma of the classic runtime accepts children as the 3rd..nth arguments, in the automatic runtime this is passed as the `children` prop. If the JSX element has one child, the `jsx` function is used and `children` is that child. If the JSX element has more, the `jsxs` function is called and `children` is an array of all childrne. If no children are passed, this prop is omitted. The third argument is the key. In the classic runtime this was part of props. If the development transform is used, `jsxDEV` from the `vue/jsx-dev-runtime` module is used intead. This is similar to `jsx` / `jsxs`, but it accepts more arguments. The 4th argument determines if the production runtime would use `jsxs` or `jsx`. The 5th argument is positional information that you could use to enhance the developer experience. Note that different compilers compile the file name differently. (relative vs absolute paths) The 6th argument is the value of `this` in the scopewhere the JSX element was created. React uses this to warn about string refs. This implementation combines the production and development runtime in the same file, and uses an package exports to expose both import entry points.
There was a problem hiding this comment.
Upon closer inspection it looks like h accepts children as either a child, multiple children, or rest arguments. So this file could probably be simplified so something like this:
import { h, Fragment } from 'vue'
function jsx(type, { children, ...props }) {
return h(type, props, children)
}
export {
Fragment,
jsx,
jsx as jsxs,
jsx as jsxDEV
}Since props are always a newly created object when passed to jsx, the following small performance enhancement could even be made to avoid another shallow copy of props:
function jsx(type, props) {
const { children } = props
delete props.children
return h(type, props, children)
}Still, would prefer you to see the original changes to get a better understanding of the JSX automatic runtime.
There was a problem hiding this comment.
This makes sense, the optimization also makes sense.
FYI Vue does recommend using its own JSX babel plugin which compiles JSX differently, these functions are meant for compatibility when the user opts for React-style JSX transforms.
There was a problem hiding this comment.
Great to see this land! Regarding “these functions are meant for compatibility when the user opts for React-style JSX transforms”, it’s good to be aware that there are differences in how React-style JSX is normally written, and what props are accepted in Vue.
Notably className vs class. But it gets quite complex around SVG (different camelcased and dash-cases attributes and tag names, xlink:href) and style (are objects accepted? Vendors prefixes with dashes or camelcase? CSS variables?).
So might be good to have some docs on how to author JSX with this, and tests that show weird SVG things work!
|
Keys should be handled; they're passed as part of the second argument of See example in docs: https://vuejs.org/guide/extras/render-function.html#v-for |
|
Good to know! In that case, export function jsx(type, { children, ...props }, key) {
return h(type, { ...props, key }, children)
}or, based on https://github.com/vuejs/core/pull/7959/files#r1148544565: function jsx(type, props, key) {
const { children } = props
delete props.children
props.key = key
return h(type, props, children)
}or wrapped in an if-statement if needed: function jsx(type, props, key) {
const { children } = props
delete props.children
if (key !== undefined) {
props.key = key
}
return h(type, props, children)
} |
The JSX automatic runtime consists of two modules. These modules require different exports.
vue/jsx-runtimeis for production. This has the following exports:jsxjsxsFragmentvue/jsx-dev-runtimeis for development. This has the following exports:jsxDEVFragmentWhereas a JSX pragma of the classic runtime accepts children as the 3rd..nth arguments, in the automatic runtime this is passed as the
childrenprop. If the JSX element has one child, thejsxfunction is used andchildrenis that child. If the JSX element has more, thejsxsfunction is called andchildrenis an array of all childrne. If no children are passed, this prop is omitted.The third argument is the key. In the classic runtime this was part of props.
If the development transform is used,
jsxDEVfrom thevue/jsx-dev-runtimemodule is used intead. This is similar tojsx/jsxs, but it accepts more arguments.The 4th argument determines if the production runtime would use
jsxsorjsx.The 5th argument is positional information that you could use to enhance the developer experience. Note that different compilers compile the file name differently. (relative vs absolute paths)
The 6th argument is the value of
thisin the scopewhere the JSX element was created. React uses this to warn about string refs.This implementation combines the production and development runtime in the same file, and uses an package exports to expose both import entry points.
This fixes some bugs introduced in #7958.
I am familiar with JSX transforms, but not with Vue. There may be better ways to fix this in a Vue specific way. Also I don’t know how to test this.
For reference, see the JS output in https://www.typescriptlang.org/play?jsx=4#code/KYDwDg9gTgLgBAYwgOwM7wGYQnAvHAbQCg44AeAEwEsA3OAegD4AaE86mxs+jlty2owDeAcgCGIgL7derUgM6iJk0QCMpMwXPaCyYJnoM8tRALpEgA. Try using both the
ReactJSXandReactJSXDevoptions forJSX. You can ignore the type errors.